Harness engineering

Voir : Comment "harness" s'est répandu en IA et pourquoi ce terme a été choisi

Ressoures

Articles que j'ai lu avec attention :

Autres articles :

Journaux liées à cette note :

Premier test minimaliste de Promptfoo avec le provider OpenCode SDK #harness, #agent-eval-harness, #llm, #AI-coding-agents, #testing, #opencode, #promptfoo, #POC

Depuis au moins novembre 2025, je cherche à rédiger mes prompts, mes fichiers AGENTS.md, mes fichiers SKILLS.md — et plus largement mon harness OpenCode — avec une méthode rigoureuse et contrôlée. J'ai découvert dans cette issue le nom du mécanisme que j'essaie de mettre en place : agent-eval-harness, terme plutôt simple et explicite.

En février, je disais :

Je compte créer un playground Promptfoo connecté à plusieurs modèles LLM dans les semaines à venir.

février 2026

Quelques mois plus tard, j'ai enfin implémenté un premier POC utilisant Promptfoo couplé avec le provider OpenCode SDK : https://github.com/stephane-klein/opencode-promptfoo-poc.

Cette première itération est volontairement minimaliste. J'ai testé :

  • 3 LLMs (dans 2 configurations chacune)
  • 3 cas de test

L'intégralité de mon évaluation tient dans un seul fichier promptfooconfig.yaml :

# yaml-language-server: $schema=https://promptfoo.dev/config-schema.json
description: "Hello World - minimal test"
providers:
  - id: opencode:sdk
    label: "without-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "without-agent-minimax-m2.7"
    config:
      provider_id: opencode-go
      model: minimax-m2.7
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "without-agent-deepseek-v4-flash"
    config:
      provider_id: opencode-go
      model: deepseek-v4-flash
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.7"
    config:
      provider_id: opencode-go
      model: minimax-m2.7
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

  - id: opencode:sdk
    label: "with-agent-deepseek-v4-flash"
    config:
      provider_id: opencode-go
      model: deepseek-v4-flash
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

prompts:
  - "Translate the following English text to {{language}}: {{input}}"

tests:
  - vars:
      language: French
      input: Hello world
    assert:
      - type: contains-all
        value:
          - "Bonjour"
          - "monde"

  - vars:
      language: Spanish
      input: Where is the library?
    assert:
      - type: contains-any
        value:
          - "Donde esta la biblioteca"
    providers:
      - "with-agent*"

  - vars:
      language: Spanish
      input: Where is the library?
    assert:
      - type: not-contains-any
        value:
          - "Donde esta la biblioteca"
    providers:
      - "without-agent*"

L'exécution de promptfoo eval donne ceci :

Et voici ce qu'affiche promptfoo viewer dans un browser :

Dans mes tests, j'ai mis en œuvre uniquement contains-all et contains-any, mais Promptfoo propose beaucoup d'autres « Deterministic metrics ».

Promptfoo propose aussi de nombreuses assertions effectuées par des modèles de langage, les « Model-graded metrics », dont la plupart peuvent être qualifiées de LLM-as-a-Judge. Je ne les ai pas encore testées.

Je n'ai pas non plus exploré l'évaluation de « Chat conversations / threads ». Par ailleurs, en examinant la documentation du provider OpenCode SDK, j'ai constaté ce qui me semble être une limitation : il n'est probablement pas possible de changer d'agent dans un thread, c'est-à-dire d'alterner entre le mode plan et le mode build, comme on le ferait dans un usage normal de OpenCode.

Mais après réflexion, il me semble que cette limitation n'est pas importante. Dans un test d'évaluation, chaque cas est un appel unique à l'agent, avec l'historique complet de la conversation fourni en contexte — il n'est pas nécessaire de simuler un flux interactif multi-tours avec alternance d'agents.

Dans ce POC, je configure le provider OpenCode SDK pour qu'il utilise le dossier de configuration ./config/opencode du repository, afin que le harness évalué soit précisément celui qui est versionné, et afin de ne pas subir de perturbation par la configuration OpenCode globale.

Quand j'ai démarré ce POC, j'ai essayé d'indiquer différentes configurations OpenCode au niveau des tests, pour tester différents fichiers AGENTS.md. Mais j'ai constaté que la configuration OpenCode ne peut être définie qu'une seule fois, ici, via une variable d'environnement XDG_CONFIG_HOME.
J'ai mis un certain temps à réaliser que je pouvais procéder autrement, en plaçant les fichiers AGENTS.md dans différents working_dir. Les working_dir se configurent au niveau des providers, voici deux exemples :

  - id: opencode:sdk
    label: "without-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

Cela permet de charger et de tester ./workdir1/AGENTS.md ou ./workdir2/AGENTS.md. Il est possible d'utiliser la même méthode pour évaluer différents SKILLS.md.

Pour le moment, je ne sais pas encore si Promptfoo est un bon outil pour mettre au point mon harness.

Avant de poursuivre mes tests de harness engineering avec Promptfoo, j'aimerais tester agent-catalog-eval pour voir si cet outil serait plus simple à mettre en œuvre.

Comment "harness" s'est répandu en IA et pourquoi ce terme a été choisi #llm, #AI-coding-agents, #testing, #agent-eval-harness, #harness

Le week-end dernier, j'ai commencé à chercher d'où venait le terme harness et pourquoi il a été choisi pour désigner ce concept dans les AI agents comme OpenCode ou Claude Code.

Cette note est le résultat de ce travail de recherche, basé sur des échanges avec Sonnet 4.6, des lectures de commentaires Hacker News et divers articles sur le sujet.

En novembre 2025, Anthropic a publié l'article « Effective Harnesses for Long-Running Agents », qui utilise explicitement « agent harness » dans le sens moderne.

Le terme « harness engineering » semble avoir été popularisé par Mitchell Hashimoto dans la section 5 de son billet publié le 5 février 2026. Il y décrit une pratique qu'il a développée au fil de son usage des agents IA :

Je ne sais pas s'il existe un terme largement accepté par l'industrie pour cela, mais j'en suis venu à appeler cela « harness engineering ». C'est l'idée que chaque fois qu'on constate qu'un agent commet une erreur, on prend le temps de concevoir une solution pour que l'agent ne commette plus jamais cette erreur. Je n'ai pas besoin d'inventer de nouveaux termes ici ; s'il en existe un autre, je m'y joindrai.

Mitchell Hashimoto — My AI Adoption Journey

Données extraites avec hackernews-trends-poc.

Jusqu'à présent, je pensais à tort que l'analogie du harnais correspondait simplement à l'équipement qu'on pose sur un cheval, sans saisir la pertinence de ce terme, par manque de culture de cette langue. En anglais, on trouve les expressions « harness the sun » ou « harness the wind ». Voici la définition du verbe harness :

Verb

harness (third-person singular simple present harnesses, present participle harnessing, simple past and past participle harnessed)

  1. (transitive) To place a harness on something; to tie up or restrain. Synonym: tackle
    « They harnessed the horse to the post. »
  2. (transitive) To capture, control or put to use. « Imagine what might happen if it were possible to harness solar energy fully. »
  3. (transitive) To equip with armour.

wiktionary

Le terme français qui me semble le plus proche du verbe harness serait « canaliser » ou « dompter ».

Le terme harness désigne donc l'action de canaliser et d'orienter la puissance d'un LLM vers un objectif souhaité.

Avant l'usage du terme harness dans le domaine de l'AI — que ce soit pour agent harness, harness engineering ou LM Evaluation Harness — j'ai découvert en travaillant sur cette note qu'il était déjà utilisé en software engineering, principalement dans l'expression test harness. Il me semble que c'était d'ailleurs l'usage principal du mot dans notre domaine, bien avant qu'il ne soit repris pour les agents IA.

Les concepts que je pense avoir identifiés et que je retiens

  • Le harness est un artefact à installer et configurer dans OpenCode. Il est composé de :
  • Le harness engineering est le processus humain d'amélioration itérative du harness. Quand l'utilisateur observe une erreur de l'agent, il modifie ou ajoute des fichiers AGENTS.md, SKILLS.md, des outils MCP ou des configurations pour qu'elle ne se reproduise plus. Ce terme désigne le processus, par opposition au harness qui est l'artefact.
  • Agent-eval-harness est un outil externe au harness permettant de lancer des sortes de tests unitaires. Il est utilisé pendant les phases de harness engineering pour valider les modifications de façon contrôlée et reproductible.

Cette note ne traite pas de la boucle agent en elle-même — j'ai documenté ce concept séparément ici :

Une application est qualifiée d'AI agent lorsqu'un LLM y prend de façon autonome des décisions en boucle pour atteindre un objectif — en appelant des tools, en consultant des sources via RAG, ou en déléguant à des sous-agents. La boucle s'arrête lorsque l'objectif est atteint ou qu'une intervention humaine est requise.

Ma cartographie de l'écosystème LLM de mars 2026

Le concept de harness vient encadrer cette boucle pour la configurer et la contraindre, mais il ne la définit pas. Comprendre la boucle aide à saisir ce qu'orchestre le harness.

Extrait d'un article de Sebastian Raschka :

Pour clarifier les concepts :

  • LLM : le modèle brut de prédiction du prochain token
  • Modèle de raisonnement : un LLM optimisé pour produire des traces de raisonnement intermédiaires et se vérifier davantage
  • Agent : une boucle qui combine un modèle avec des outils, de la mémoire et des retours d'environnement
  • Agent harness : le scaffold logiciel autour d'un agent qui gère le contexte, l'utilisation des outils, les prompts, l'état et le flux de contrôle
  • Coding harness : un cas particulier d'agent harness ; un harness spécifique au génie logiciel qui gère le contexte du code, les outils, l'exécution et les retours itératifs

source

Quelques articles que j'ai lus avec attention :

En explorant le sujet de harness, je constate que, comme beaucoup de concepts, sa définition peut varier selon les sources et les communautés. Par exemple, l'article Components of a Coding Agent de Sebastian Raschka semble en proposer une définition plus large que Mitchell Hashimoto.

Pour le moment, je souhaite adopter la version de Mitchell Hashimoto, que j'arrive mieux à appréhender et dont je parviens mieux à délimiter le périmètre : un dispositif qui canalise la fougue du LLM, comme le harnais canalise le cheval sauvage.